The present invention relates to interactive voice response (IVR) systems. More particularly, the invention relates to interactive voice response systems that include multiple general-purpose blocks.
As technology advances, more and more functions that are traditionally performed by human beings are being performed by machines. As an example, receptionists were the standard at almost any level of business to answer phone calls and direct them to the intended recipient. However, today it is very common for machines to perform the functions of a receptionist. When one calls a number, a machine often prompts the caller with a number of choices, which the caller can select with the buttons of a touch tone phone.
The electronic receptionist described above is a simple example of an IVR system. IVR systems are increasingly becoming more and more complex and can perform functions including voice processing, fax processing, call switching, call management, and the like. As may be expected, the complexities of the IVR systems provide more flexibility but also make building and maintaining an IVR system much more difficult.
IVR systems can be created using scripting languages. A scripting language is a relatively simple programming language that is designed for a specific task. The logical flow of an IVR system can be defined using sequential statements of the scripting language (e.g., javascript). Typically, the script statements are compiled into a software application that runs the IVR system.
Although scripting languages can be fairly powerful, they have several drawbacks. Most scripting languages are designed to resemble programming languages in order to reduce the learning curve for script programmers. However, this makes it difficult for one who is not a programmer to create, modify and generally maintain the IVR system. Additionally, if the software application is compiled from a script program, the IVR system will have to be terminated or “brought down” in order to update the software application with any changes.
IVR systems can also be created by the use of graphical application generators. Application generators commonly include a library of predefined software modules represented by graphical icons that the user is able to select and connect in order to build the software application. FIG. 1 shows an example of an application generator for building an IVR system. As shown, a window 101 includes multiple interconnected graphical icons, providing an application generated from the interconnected predefined modules.
A graphical icon 103 is the point in which the software application begins. A graphical icon 105 is a branch that allows the flow of execution to proceed along multiple paths. Taking the middle path, a graphical icon 107 allows the user to enter his or her personal identification number (PIN), which is verified at a graphical icon 109. A message is played to the user at a graphical icon 111 and the software application exits at a graphical icon 113.
The particular logic flow of the software application shown in FIG. 1 is not as important as understanding how the application generator works. In general, a user selects a desired icon from an icon window 115. The selected icon is displayed on the screen and the user is able to connect the icon to other graphical icons. Additionally, the user may be able to define the specific characteristics of an icon. For example, the user may be able to specify the conditions upon which the graphical icon 105 will branch to each of the possible branch options.
Although application generators make creating and maintaining IVR systems easier, they still can be difficult to master. For example, there are possibly over 50 graphical icons shown in FIG. 1, with each icon being designed for a specific purpose. Although the graphical image of the icons may aid the user's understanding of the function that is provided, it still may be difficult to fully master the power and capabilities provided. Additionally, once the application is configured, the application generator generates an executable software module that needs to be executed in order to have the application run and perform the functions the user has configured. If there is a change in the configuration, the application generator needs to generate the executable software module that executes the newly modified version of the application before the configuration change takes effect. However, in systems that require non-stop operation, it is not practical to terminate an old version of the application so that the newly modified version can be started. This can make it difficult to modify a running IVR system because the running software application may need to be brought down, in order to install the updated version.